Closed Bug 1226236 Opened 9 years ago Closed 4 years ago

Allow user to remove saved login/password when being asked to update it

Categories

(Toolkit :: Password Manager, enhancement, P3)

enhancement

Tracking

()

VERIFIED FIXED
mozilla78
Tracking Status
firefox78 --- verified

People

(Reporter: rfeeley, Assigned: bdanforth)

Details

(Whiteboard: [passwords:capture-UI])

Attachments

(3 files)

As the last option in the split button in the Update Login/Password door hanger, there should be the option Remove login/password.

Often a user won't want to update the password, and may even prefer to have it more easily removed.
Whiteboard: [passwords:capture-UI]

I believe rgaddis also wanted this.

Priority: -- → P3

I'm a firm believer that you need to help users maintain good password hygiene by letting them create, update and delete entries at every possible interaction. What do you think Ryan G?

Flags: needinfo?(rgaddis)

Agreed. Katie is working through the logic in this and other instances.

Flags: needinfo?(rgaddis) → needinfo?(kcaldwell)

Ryans:
I thought I had this figured out, but then... I started questioning adding "Remove saved login" in an "Update" doorhanger. While I agree we want to "help users maintain good password hygiene" - is this is the appropriate time/place for password management?

The use cases: (what others am I missing?)
a) the user is changing/modifying their password (intentionally)
b) the user has chosen to generate a secure password (with Fx pwd dropdown menu) which autosaves, then the user modifies that generated password
c) the user has changed their password in another browser

If the user actively uses Lockwise, why want to delete the login in this specific moment? Seems like we'd be distracting the from their current path/focus.

If the user has decided to use another password management tool (app, paper, memory, etc), the user can easily choose to ignore/dismiss the doorhanger or actively choose "Don't Update".

If the user does decide they want to delete logins from Lockwise while signing into an account (though why would they change their attention/goal now), there's a link in the drawer to "View Saved Logins" - which they see before seeing the doorhanger.

Another consideration as I explore login removal/deletion in Lockwise : a login could be associated with 1 or more sync'd devices. In that case, it might be important to remind/warn/offer an undo, which seems like unnecessary complexity in a doorhanger.... which as I understand so far are for single concepts (save/dont save/never save or update/don't update).

Thoughts?

Flags: needinfo?(rgaddis)
Flags: needinfo?(rfeeley)
Flags: needinfo?(kcaldwell)

Per our conversation yesterday, we may consider a different, broader approach for handling read-only and delete use cases, independent of the task of updating or saving a given login.

Flags: needinfo?(rgaddis)
Comment on attachment 9129889 [details]
Update Doorhanger with remove login toast

UX Recommendation: 
• When we present the Update Doorhanger, give the user the option to "Remove Saved Login". 
   • Update the "Don't Update" button to have dropdown with remove option (see attached screenshot, match the "Don't Save/Never Save" doorhanger button)
• Delete login record from Lockwise and display confirmation toast "Login removed!"
Assignee: nobody → bdanforth
Status: NEW → ASSIGNED

katieC: Is there anything we might want to do differently if the user edits one or both of the login fields in the update doorhanger and then clicks Remove Saved Login? The edited values would be discarded currently. E.g. we could disable the Remove Saved Login button if either field is edited. I don't know if that would be more or less confusing. What do you think?

Flags: needinfo?(kcaldwell)
Attachment #9144525 - Attachment description: Bug 1226236 - Allow user to remove saved login/password when being asked to update it → Bug 1226236 - Allow user to remove saved login/password when being asked to update it; r=MattN

(In reply to Bianca Danforth [:bdanforth] from comment #9)

katieC: Is there anything we might want to do differently if the user edits one or both of the login fields in the update doorhanger and then clicks Remove Saved Login? The edited values would be discarded currently. E.g. we could disable the Remove Saved Login button if either field is edited. I don't know if that would be more or less confusing. What do you think?

That's a great question. From a UX standpoint, with the remove option in a submenu, we can hypothesis that the user hasn't accidentally selected this option over the blue, and more prominent, "Update" button. Also important to consider, if we were to disable the button, and incorrectly assumed the user's edits were intentional - the user then can no longer remove the login, which would be a frustrating experience. IIRC, there was a discussion about adding an "undo" to the confirmation toast ("Login removed"), but at the time is was considered to be technically challenging.

Flags: needinfo?(kcaldwell)

Just to make sure you understand the concern… the issue is that there are three things the user could think they are deleting:

  1. the values they just submitted
  2. the values that were saved before - This is what we will actually delete
  3. the edits in the doorhanger

I could easily see a user thinking they are deleting #1 or #3 but are actually deleting #2

The undo option won't be useful in this case unless their understanding of which of the 3 we deleted changed at that point.

I do think the string does help in this case "Remove Saved Login" it's something to watch out for though since there is data loss involved.

Flags: needinfo?(rfeeley)
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/941aaea7104e
Allow user to remove saved login/password when being asked to update it; r=MattN
Flags: qe-verify+
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78

Verified - fixed on latest Nightly from Treeherder on Windows 10, Ubuntu 18 and MacOS 10.13/14/15.

The Remove Saved Login option is correctly displayed in the dismissed or Update doorhanger after editing the password of autofilled credentials, the credentials are removed and the toast is also confirming that.

However, on MacOS, that option is placed slightly off, check the attached screenshot. @Bianca, would it be better to file a separate bug for this?

Flags: needinfo?(bdanforth)

Thanks Timea for verifying this and bringing this up (especially the screenshot). What do you mean by "the option is placed slightly off" here? Do you see this same issue e.g. for the "Never Save" option in the Save doorhanger?

Either way, I would say anything related to the appearance of the "Remove Saved Login" item in the doorhanger is outside of the scope of this bug, as I am using the existing UI and just passing the string in (and specifying what to do if the button is clicked).

This UI (PopupNotifications.jsm) is actually used by lots of different components in Firefox. If you have found a bug in it, I think the right place to file it would be Firefox::General based on other bugs that have modified that UI in the past.

Flags: needinfo?(bdanforth)

Thanks Bianca, the problem is that the string takes up more space compared to "Never Save" (especially that is centered) and cause the UI to look as you see it in the screenshot, but this is something that could be addressed in a separate bug. (this is also macOS specific)
Marking this as verifed-fixed on the latest Nightly 78.0a1 (2020-05-14) (64-bit) on Windows 10, MacOS 10.13 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressions: 1650973
No longer regressions: 1650973
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: